ing for Displays

Let us now entertain the notion that we could, at this stage, be forever more happy with our #tex2html_wrap_inline4042#
1 display technology. Excluding the fact, for the moment, that modern computer equipment already has a half-life shorter than most pairs of socks, would the general <#593#>principles<#593#> of #tex2html_wrap_inline4044#
1 antialiasing be such that we would never desire to venture to any #tex2html_wrap_inline4046#
n for n ;SPMgt; 1? That this is not an unreasonable notion is supported by the simple fact that #tex2html_wrap_inline4049#
0 technology has been widespread for about twenty years, and seems to be complaining about <#597#>it<#597#>. (Yet.) On the other hand, since this section does not end at the end of this sentence, the reader is no doubt anticipating that the story of our hypothetical viewer is not yet complete.

The main problem with our simplistic examples above, which will show why they are not completely representative of the real world, is that they are all <#598#>one-dimensional<#598#>. Of course, we can tranform the ``falling'' example to a ``projectile'' situation by simply superimposing an initial horizontal velocity on the vertical motion; this would simply require applying the uniform motion and uniform acceleration cases cojointly. However, we have also simplified the world by only talking about some unspecified, featureless, Newtonian-billiard-ball-like ``object'', without worrying about the extended three-dimensional structure of the object. A 2-D world, of course, is infinitely more interesting than a 1-D world, not least because it becomes possible to step <#599#>around<#599#> other people, instead of simply bouncing into them. In a ``2#tex2html_wrap_inline4051#
-D'' system---such as in many video games, or Microsoft Windows---<#600#>three<#600#>-dimensional structure is represented by painting the object with depth-emulating visual clues; but the objects still only move, effectively, in two dimensions. On the other hand, in a manifestly three-dimensional environment such as , the two-dimensional display is a subtle <#601#>perspective projection<#601#> of the virtual three-space. Objects in such virtual worlds, unlike their 2-D or 2#tex2html_wrap_inline4053#
-D counterparts, are free to rotate about arbitrary axes, as well as to move closer to or further from the participant. The <#602#>apparent<#602#> motion of the objects on the display device is a complicated interplay between the physical motion of the objects, the physical motion of the participant, and the mathematical transformations yielding the perspective view. It is important that we consider more general forms of motion, such as this, before drawing any general conclusions about whether #tex2html_wrap_inline4055#
1 antialiasing is good enough for practical purposes.

In fact, a fairly simple example will suffice to illustrate the problems that are encountered when we move up from 1-D to 2-D or 3-D motion. Consider a two-dimensional square, in the plane of the display, which is also <#604#>uniformly rotating<#604#> in that same plane about the centre of the square. Choose any point on the boundary of this square. The path traced out by this point in time will be a <#605#>circle<#605#> (as is simply verified by considering that point alone, without the complication of the rest of the square). Now, a #tex2html_wrap_inline4057#
0 display will represent this rotating point as a series of discrete points on the circle: the overall display will show successive renderings of a square in various stages of rotation, from which the viewer will (hopefully) be convinced that it is a single square undergoing a somewhat jerky rotation.

Now consider how a #tex2html_wrap_inline4059#
1 display will render this rotating square. The <#608#>velocity<#608#> of our chosen point on the square will depend on how far the point is from the centre of the square; its direction will be perpedicular to the line joining it to the centre. Consider what happens when we propagate forward in time from this position, using only the velocity information: the point moves in a <#609#>straight line<#609#>. But we really want it to travel in a circle! What will happen to the square? Well, for very small times, the square will indeed be rotating beautifully---a vast improvement on the #tex2html_wrap_inline4061#
0 situation. If we keep propagating the square further, however, we find a disconcerting feature: <#611#>the square is slowly growing larger as it rotates!<#611#> Propagate yet further and this growth dominates, and the rotation slows to a trickle. Of course, when the next update comes along, the square spontaneously shrinks again---not a good solution.

It might be argued that this example merely shows that you cannot stretch the ing procedure indefinitely; ultimately, you must update the display at a <#612#>reasonable<#612#> rate, even if that is considerably lower than the refresh rate. To a certain extent, this is indeed true. However, rejecting #tex2html_wrap_inline4063#
1 antialiasing as an optimal solution, due to its poor performance for rotation, can be justified on the basis of a good ``rule of thumb'' in Science: Approximating an arbitrary curve by a straight line is usually pretty bad; approximating it with a parabola is infinitely better; approximating it with a cubic <#614#>may<#614#> be worthwhile; using anything of higher order is probably a waste of resources, unstable, or both. For sure, this is not a definitive law of Nature, but in any case it suggests that we may be much better off going to #tex2html_wrap_inline4065#
2, or perhaps #tex2html_wrap_inline4067#
3, rather than sticking simply with #tex2html_wrap_inline4069#
1 technology.

This purely mathematical line of reasoning, while most helpful in our deliberations, nevertheless again overlooks the fact that, ultimately, all that matters is what the viewer <#618#>thinks<#618#> she is seeing on the display, not how fancy we are with our mathematical prowess. To investigate this question more fully, it is necessary to perform some investigations of a psychological nature that are not completely quantitive. These deliberations, however, shall require an additional piece of equipment, readily available to the author, but (unfortunately) not to all workers: a <#619#>Melbourne tram<#619#>. (Visitors to the mecca of Seattle can, however, make use of the authentic Melbourne trams that the city of Seattle bought from the Victorian Government ten years ago, which now trundle happily along the waterfront with a view of Puget Sound rather than Port Phillip Bay.) Melbourne trams (the 1920s version, not the new ``torpedo'' variety) have the unique property that, no matter how slowly and carefully they are moving, they always seem to be able to hurl standing passengers spontaneously into the lap of the nearest seated passenger (which may or may not be an enjoyable experience, depending on the population of the tram). This intriguing (if slightly frivolous) property of such vehicles can actually be used as a reasonably quantitative experimental investigation of the kinematical capabilities of humans.

Consider a Melbourne tram located in the Bourke Street Mall, sitting at the traffic lights controlling its intersection with the new Swanston Street Mall. A passenger standing inside the tram looks out the window. Apart from wondering why on earth Melbourne needs so many malls---or indeed why one needs traffic lights at all at the intersection of two malls---the passenger is unperturbed; she can take a good look at the surrounding area. She drops a cassette from her Walkman into her handbag: it falls straight in.

Now consider the same tram thirty seconds later, as it is moving at a constant velocity along Bourke Street. The standing passenger is again simply standing around; cassettes drop fall straight down; if it were not for the passing scenery, she wouldn't even know she was moving. And, of course, physics assures us that this is always the case: inertial motion cannot be distinguished from ``no'' motion, except with reference to another moving object. The laws of physics are the same.

We now take a further look at our experimental tram: it is now accelerating across the intersection at Russell Street. Old Melbourne trams, it turns out, have quite a constant rate of acceleration when their speed controls are left on the same ``notch'', at least over reasonable time periods. Let us assume that this acceleration is indeed constant. With our knowledge of physics, we might predict that our standing passenger might have to take some action to avoid falling over: the laws of Newtonian physics <#620#>change<#620#> when we move to an accelerated frame. Inertial objects do not move in straight lines. Cassettes do not fall straight down into handbags. Surely this is a difficult environment in which to be merely standing around?

Somewhat flabbergasted, we find our passenger standing in the accelerated tram, not holding onto anything, unperturbedly reading a novel. How is this possible? Upon closer examination, we notice that our passenger is <#621#>not<#621#> standing exactly as she was before: <#622#>she is now leaning forward<#622#>. How does this help? Well, to remain in the same position in the tram, our passenger must be accelerated at the same rate as the tram. To provide this acceleration, she merely leans forward a little. The force on her body due to gravity would, in a stationary tram, provide a torque that would topple her forwards. Why does this not also happen in the accelerating-tram case then? The answer is that the additional forward frictional force of the tram's flooring on her <#623#>shoes<#623#> both provides a counter-torque to avoid her toppling, as well as the forward force necessary to accelerate her at the same rate as the tram. Looked at another way, were she to <#624#>not<#624#> lean forward, the frictional force forward of the accelerating tram would produce an unbalanced torque on her that would topple her <#625#>backwards<#625#>.

Leaning forward at the appropriate angle is, indeed, a fine trick on the part of our passenger. Upon questioning, however, we find to our dismay that she knows nothing about Newtonian mechanics at all. We must therefore conclude that ``learning'' this trick must be something that humans do spontaneously---everyone seems to get the hang of it pretty quickly.

It should be noted that <#626#>this trick would not work in space<#626#>. Without borrowing the gravitational force, there is no way to produce a counter-torque to that provided by the friction on one's shoes. Of course, this friction <#627#>itself<#627#> should not be relied on too much: without any gravitational force pushing one's feet firmly into the floor, there may not be any friction at all! This means that there will, in general, be no unbalanced torque to topple one backwards anyway: the passengers in an accelerating space vehicle, (literally) hanging around in mid-air, will simply continue to move at constant velocity. But the accelerating vehicle will then catch up to them: they will slam against the <#628#>back<#628#> wall of the craft! Of course, this is precisely Einstein's argument for the Equivalence Principle between gravity and acceleration---if you are a standing passenger, you had better find what will become the ``floor'' in your accelerated spacecraft quick smart---but it shows that life on earth has prepared us with different in-built navigation systems than what our descendents might require.

What lessons do we learn from this? Firstly, it is unwise to put a Melbourne tram into earth orbit. More importantly, it shows that humans are quite adept at both extrapolating the effects of constant acceleration (as shown by our ability to catch projectiles), as well as being able to function quite easily in an accelerated environment (as shown by our tram passenger).

Let us now examine the tram more closely <#629#>before<#629#> it accelerates away. It is now sitting at the traffic lights at Exhibition Street. The lights turn green. The driver releases the tram's air-brakes with a loud hiss. Our passenger spontaneously takes hold of one of the overhanging stirrups! More amazingly, another passenger spontaneously starts to fall forwards! The tram jerks, and accelerates away across Exhibition Street. Our passenger, grasping the stirrup, absorbs the initial jerk and, as the tram continues on with a constant acceleration, lets go in order to turn the page of her novel. The second passenger, the spontaneously-falling character, magically did not fall down at all: the tram accelerated at just the right moment to hold him up---and there he is, still leaning forward like our first passeneger! However, all is <#630#>not<#630#> peaceful: a Japanese tourist, who boarded the tram at Exhibition Street, has tumbled into the lap of a (now frowning) matronly figure, and is struggling to regain his tram-legs.

What do we learn, then, from this experience? Clearly, the Japanese tourist represents a ``normal'' person. Accustomed to acceleration, but <#631#>not<#631#> to the discontinuous way that it is applied in Melbourne trams, he became yet another veteran of lap-flopping. Our first passenger, on the other hand, who grabbed the stirrup upon hearing the release of the air-brakes, had clearly suffered the same fate in the distant past, and had learnt to recognise the audible clue that the world was about to shake: such is the Darwinian evolution of a Melburnite. The second passenger, who spontaneously fell forward, appears to be an even more experienced tram-dweller: by simply falling forward he had no need to grasp for a stirrup or the nearest solid structure. This automatic response, which relies for its utility on the fact that Melbourne tram-driving follows a fairly standard set of procedures, is perhaps of interest to behavioural scientists, but does <#632#>not<#632#> indicate that the passenger had any infallible ``trick'' for avoiding the effects of jerks (to employ Feynman's term)---the ``falling'' method does not work at all if the jerk is significantly delayed for some unknown reason. (A somewhat mischievous tram driver once confessed that his favourite pastime was releasing the air-brake and then not doing anything---and then watching all of the passengers fall over.) Of course, the Melbourne trams on the Seattle waterfront have an extra reason for unexpected deceleration: in a city covered by decrepid, unused <#633#>train<#633#> tracks, motorists turning across the similar-looking <#634#>tram<#634#> tracks get the fright of their lives when they find a green, five-eyed monster bearing down on them!

Returning, now, to the task at hand, our admittedly simplified examples above show that people are, in general, relatively adept at handling <#635#>acceleration<#635#> (not surprising, considering our need to deal with gravity), but not too good when it comes to <#636#>rate of change<#636#> of acceleration, or <#637#>jerk<#637#>. Numerous other examples of this general phenomenon can be constructed: throw a ball and a person can usually catch it; but half-fill it with a liquid, so that it ``swooshes around'' in the air, and it can be very difficult to grab hold of. Sitting in a car while it is accelerating at a high rate ``feels'' relatively smooth; but if the driver suddenly lets off the accelerator just a little, your head and shoulders go flying forward---despite the fact that you are still being accelerated in the <#638#>forward<#638#> direction! In each of these examples, it is the (thus appropriately named) <#639#>jerk<#639#> that throws our inbuilt kinematical systems out-of-kilter; not too surprisingly, it is difficult to formulate uncontrived examples in the <#640#>natural<#640#> world in which jerks are prevalent (apart from falling out of a tree, of course---but repeatedly hitting the ground is not a technique well suited to evolutionary survival).

We now have two pieces of information on which to base a decision about what n should be in a practical #tex2html_wrap_inline4072#
n display system. Firstly, we have a purely mathematical ``rule of thumb'': n should be either 2 or 3 to represent most efficiently (and stably) arbitrary motion around t = 0. Secondly, we have a psychological criterion: we have recognised that, in rough terms, the human kinematical-computation system is comfortable with dealing with motional derivatives up to the second, but is quite uncomfortable dealing with the third derivative; this suggests that n should probably be 2, or, at the most, 3. There is, however, a <#642#>third<#642#> consideration to be taken into account in this question, that has nothing to do with mathematics nor psychology, but rather basic physics and information theory: How many derivatives of the motion can we <#643#>accurately specify<#643#> in a realistic situation, in which many of the relevant physical quantities are not merely generated by the computer, but are, in fact, measured by physical transducers? To answer this question, we need to look a little more closely at the physical transducers that are used in real-life systems, as well as the way that the data they produce is analysed by the system itself.

Clearly, positional--rotational data is the common denominator among existing transducer technology: find some physical effect that lets you determine how far away the participant is from a number of fixed sensors, as well as her orientation with respect to these sensors, and you ``know where she is''. Transducers for <#644#>velocity<#644#> information---which tell you ``where she's going'' (but not ``where she is'')---are also commonplace in commerical industry, albeit less common in . However, even if such transducers are <#645#>not<#645#> used, quite a reasonable estimate of the true velocity of an object may be obtained by taking differences in positional data (as was used to calculate the results in <#646#>ComputeVel<#646#>). On the other hand, this ``numerical differentiation'' carries two inherent dangers: firstly, computing <#647#>any<#647#> differentiation on physical data enhances any high-frequency noise present; and, secondly, performing a <#648#>discrete-time<#648#> numerical differentiation introduces lags into the data (, in rough terms, you need to wait until t = 5 to compute #math119#f (5) - f (4) #tex2html_wrap_inline4082#
f'(4.5)). The first problem can be somewhat ameliorated by low-pass filtering; the second by ``extrapolating'' the data forwards half a time interval; unfortunately, these two solutions are largely mutually exclusive. However, in practice, quite reasonable velocity information <#649#>can<#649#> in fact be obtained---as long as it is treated with care.

In a similar way, acceleration can either be measured directly, or computed from the velocity data by discrete numerical differentiation. In many respects, the laws of Nature make accelerometers <#650#>easier<#650#> to make than speedometers. This is, of course, due to the fact that <#651#>uniform motion is indistinguishable from no motion at all<#651#>, as far as Newtonian mechanics is concerned: it is vitally necessary to measure velocity ``with respect to something'' (such as the road, for an automobile; or the surrounding air, for an aeroplane---``ground speed'' being much more difficult to measure because there is [hopefully] no actual contact with the ground!). On the other hand, <#652#>accelerations<#652#> cause the laws of physics to change in the accelerated frame, and can be measured without needing to ``refer'' to any outside object. (Of course, this is not completely true: if (classical) laws of physics are written in a <#653#>generally relativistic<#653#> way, they will also hold true in accelerated frames; but that is only of academic interest here.) Nevertheless, even though these properties make acceleration inherently easier to measure than velocity, the designer must ultimately worry about both minimising the cost of the system, and minimising the number of gadgets physically attached to the participant---and it is unlikely that <#654#>both<#654#> velocity and acceleration transducers would be deemed necessary; one or the other (or, indeed, both) would be omitted. Of course, acceleration may be deduced from velocity data numerically, and carries the same dangers as velocity data obtained numerically from positional data. Most dangerous of all is if acceleration data must be numerically obtained from velocity data that was <#655#>itself<#655#> obtained numerically from positional data; the errors compound.

Of course, it is also possible actually <#656#>omit<#656#> measuring positional information altogether, and instead obtain it by integrating measured velocities. This integration actually <#657#>reduces<#657#> high frequency noise---but what one gains on the swings one loses on the roundabouts: the <#658#>low<#658#> frequency noise is boosted---manifested, of course, in ``drift'' in the measured origin of the system, which must be regularly calibrated by some other means. Alternatively, the relative simplicity of the physics may lead a designer to simply use <#659#>accelerometers<#659#> as transducers, integrating this information once to obtain velocity data, and a second time to obtain positional data. Of course, this double-integration suppresses high-frequency noise even further, but requires regular calibration of not only the origin of the <#660#>positional<#660#> system, but also of the origin of the <#661#>velocity<#661#> information ( knowing when the transducer is ``stationary'' with respect to the laboratory)---which is again a manifestation of the general Wallpaper Bubble Conservation Law ( whenever you get rid of one problem it'll usually pop up somewhere else).

Keeping in mind the above technical and design concerns involved in determining even positional, velocity and acceleration information from physical transducers, what chance is there for us to extend this methodology to measuring <#662#>jerk<#662#> data? On the physics side, there are few (if any) genuinely simple physical effects that could inspire the design of a <#663#>jerkometer<#663#> (to coin a somewhat obscene-sounding term). It is not even clear that a jerkometer would be all that reliable an instrument anyway: since (by Newton's Second Law, #math120##tex2html_wrap_inline4084#
F = m#tex2html_wrap_inline4085#
) <#665#>accelerations<#665#> are caused by <#666#>forces<#666#>, we see that <#667#>jerks<#667#> are caused by <#668#>rates of change of forces<#668#>. Think, now, of what happens when (for example) you lift your leg: at some instant in time you decide, ``Hmm, I'd like to lift my leg''; your leg muscles then start to apply a force which overcomes gravity and begins to accelerate your leg upwards. The point is that <#669#>the force itself is applied rather abruptly<#669#>---in other words, the <#670#>jerk<#670#> is almost like an <#671#>impulse function<#671#> (or an ``infinite prick'' as it is sometimes derogatorily termed). The main problem with impulse functions is that, due to fact that they reach extremely high peak values (for short values of time, such that the area underneath their curve is constant), many physical devices encountering them either <#672#>clamp<#672#> them to their peak-allowable value (rendering the area under the impulse inaccurate), or get driven into <#673#>non-linear behaviour<#673#> (which can not only scramble the area-under-curve information, but may indeed drive the whole system into instability). Thus, one would need to be very careful in implementing directly a jerk transducer. Of course, even if one <#674#>were<#674#> able to manufacture such a jerkometer, incorporating it into equipment would again come up against the abovementioned barriers of transducer overpopulation and excessive cost.

On the numerical-differentiation side, on the other hand, whether it would be wise or not to perform an extra differentiation of the acceleration data to obtain the jerk data depends largely on where the acceleration information originates. If it is obtained from an actual physical accelerometer, such a numerical differentiation would probably be reasonable. However, if the physical transducer is in fact a velocity- or position-measuring device, then one would not wish to place too much trust on a second- or third-order numerical derivative for a quantity that is already subject to concerns in terms of basic physics: most likely, all one would get would be a swath of potentially damaging instabilities in the closed-loop system. Thus, a numerical approach depends intimately on what order of positional information is actually yielded by the physical transducers.

We now make the following suggestion: The visual display architecture of technology should make only <#675#>minimal<#675#> assumptions about the nature of the physical tranducers used elsewhere in the system. This suggestion is based, of course, on the concept of <#676#>modularity<#676#>: if groups of functional components in any system cohere, by their very intrinsic nature, into readily identifiable ``modules'', then any one ``module'' should not be made unnecessarily and arbitrarily dependent on the internal nature of another ``module'' <#677#>unless<#677#> the benefits gained from whole outweigh the loss of encapsularity of the one. If this suggestion is accepted (which, in some proprietary situations, may require consideration of the future health of the industry rather than short-term commerical leverage), then it is clear that it would be inappropriate for a display system to assume that a given environment obtains anything more than raw positional--rotational information from physical transducers. With such a minimalist assumption, our above considerations show that it would <#678#>not<#678#> be wise, in general, to insist that jerk information about the physical motion of the participant be provided to the display system. Of course, this does not prevent jerk information being obtained about the other <#679#>computer-generated<#679#> objects in the virtual world---their trajectories in space are (in principle) knowable to arbitrary accuracy; arbitrary orders of temporal derivative may be computed with relative confidence. However, if a display system <#680#>did<#680#> use jerk information for virtual objects, but not for the participant herself, it would all be for naught anyway. To appreciate this fact, it is only necessary to note that <#681#>all<#681#> of the visual information generated in a virtual world scenario <#682#>depends solely on the relative positions of the observer and the observed<#682#>. Differentiating the previous sentence an arbitrary number of times, it is clear that the <#683#>only<#683#> relevant velocities, accelerations, jerks, , in a Galilean antialiased display environment are the <#684#>relative<#684#> velocities, accelerations, jerks, , of the observer and the observed. Of course, this property of <#685#>relativity<#685#> is a fundamentally deep and general principle of physics, whether it be Relativity, or Einstein's Special Relativity or General Relativity; it will probably not, however, be an in-built and intuitively obvious part of humanity's subconscious until we more regularly part company with <#686#>terra firma<#686#>, and travel around more representative areas of our universe. (Ever played <#687#>Wing Commander<#687#>? Each Terran spacecraft has a maximum speed. But <#688#>with respect to what?!<#688#> Galileo would turn in his grave....) Thus, using jerk information for one half of the system (the virtual objects) but not the other half (the participant) brings us no benefits at all---and, indeed, the inconsistencies in the virtual world that would result may well be a significant degradation.

Returning, again, to the task at hand, the above deliberations indicate that, all in all, the most appropriate order of Galilean antialiasing that should be used, at least for applications, is probably #tex2html_wrap_inline4087#
2. Of course, much of the above relies on only back-of-the-envelope, first-principles arguments, which may well be rejected upon a more careful investigation; and, of course, anyone is free to develop technology to whatever specifications they like, if they believe that their end product will be marketable. However, for the purposes of the remaining sections of this , we shall assume that #tex2html_wrap_inline4089#
2 antialiasing is used exclusively; the results obtained, and conclusions drawn, would need to be extended by the reader if a different order of antialiasing were desired.

<#691#>MinimalImplementation<#691#><#692#>A Minimal Implementation<#692#> The previous sections of this have been concerned with the development of the underlying philosophy of, and abstract planning for, ing in general. In this section, we turn directly to the practical question of how one might retrofit these methods to existing technology. Section~<#693#>MinHardwareMods<#693#> outlines the minimal modifications to existing display control hardware that must be implemented; section~<#694#>MinSoftwareMods<#694#> describes, in general terms, the corresponding software enhancements necessary to drive the system. More advanced enhancements to the general visual-feedback methodology of ---which would, by their nature, be more amenable to implementation on new, ground-up developments---are deferred to section~<#695#>Enhancements<#695#>.

<#696#>MinHardwareMods<#696#><#697#>Hardware Modifications and Additions<#697#> Our first task in modifying an exisiting system is to determine precisely what changes must be made to its hardware: if such changes are technically, financially or politically unattainable, then a retrofit will not be possible at all, and further speculation would be pointless. Clearly, the area of existing #tex2html_wrap_inline4091#
0 technology that has been subjected to most scrutiny in this is the <#699#>video controller subsystem<#699#>. As would by now be obvious, the sample-and-hold frame buffer methodology of conventional display systems, as described in section~<#700#>CurrentRasters<#700#>, must be completely gutted; in its stead must be installed a tightly-integrated, relatively intelligent video controller subsystem capable of correctly propagating from frame to frame the moving, accelerated (but pixelated) objects passed to it by the display processor. We shall assume, in this , that <#701#>refresh-rate ing<#701#> is to be retrofitted; in other words, the video controller computes a new, correctly propagated frame for <#702#>each<#702#> physical refresh of the display device. This is, of course, the most desirable course of action: the motion depicted on the display device should then (if its physical refresh rate is suitably high) be practically indistinguishable from smooth motion. However, in a retrofit environment, memory- and circuitry-speed constraints may quite possibly render this goal unachieveable. In such a situation, <#703#>sub-refresh-rate antialiasing<#703#> may be opted for: the actual ``frame period'' used for the propagation circuitry would, in that case, be chosen to be some integral multiple of the physical refresh period, the propagator update rate would then be a sub-harmonic of the physical refresh rate. For example, for a display system with a 60~Hz physical refresh rate, a `` refresh rate'' of 30~Hz, or 20~Hz, or 15~Hz, , may be chosen instead of the full 60~Hz. Such an approach, however, carries the potential for many headaches: the existing pixmap frame buffers used by the scan-out circuitry may (or may not) need to be retained, with <#704#>additional<#704#> pixmap buffers for the propagation process; the results may then need to be copied at high speed from the propagation frame buffer to one of the scan-out frame buffers; and so on. In any case, sub-refresh-rate ing will not be specifically treated in the following; practitioners wishing to use this technique will need to take references to ``refresh rate'' and ``frame buffers'' to mean the corresponding objects in the <#705#>propagation<#705#> circuitry; requirements for the <#706#>scan-out<#706#> versions of these objects must then be inferred by the practitioner.

As noted in section~<#707#>Galpixels<#707#>, the galpixmaps that will be stored in the (now necessarily multiple) frame buffers extend significantly on the simple intensity or colour information stored in a regular pixmap. However, there is clearly no need for a galpixmap to be <#708#>physically<#708#> configured as a rectangular array of galpixel structures (in terms of physical memory); rather, a much more sensible configuration---especially in a retrofit situation---is to maintain the existing hardware for the frame buffer pixmap (and duplicate it, where necessary), and construct new memory device structures for storing the additional information, such as velocity and acceleration, that the galpixmap requires. The advantage of this approach is that, properly implemented, the detailed circuitry responsible for actually scanning out the frame buffer to the physical display device may be able to be left unchanged (apart, perhaps, for including a frame-buffer multiplexer if hardware double-buffering is not already employed by the system). This is a particularly important simplification for retrofit situations, since, in general, the particular methodology employed in the scan-out circuitry depends largely on the precise nature of the display technology used.

We now turn to the question of what information <#709#>does<#709#> need to be stored in the extended memory structures that we are adding to each frame buffer. Clearly, the (``display'', or ``apparent'') <#710#>position vector<#710#> of the i-th galpixel, #tex2html_wrap_inline4094#
(where i runs from 1 up to the number of pixels on the display), is already well-spoken for: its x and y components are, by definition, already encoded by the galpixel's physical location in the pixmap matrix; and its z component is stored in the hardware z-buffer memory structure. (If a hardware z-buffer is already implemented in the system, it can be used unchanged; if a hardware z-buffer is <#711#>not<#711#> present, it <#712#>must<#712#> be added to the system at this point in time; its presence is vital for antialiasing, as will soon be apparent.) Is this all the positional information that we require? What might be surprising at first sight is that, in fact, <#713#>it is not<#713#>; we must, however, first turn to the other memory structures required, and the propagation algorithm itself, to see why this is so.

The <#714#>velocity vector<#714#> of the i-th galpixel, #tex2html_wrap_inline4105#
, is a new three-component piece of data that the display processor must now provide for each galpixel; likewise, the <#715#>acceleration vector<#715#> of the i-th galpixel, #tex2html_wrap_inline4108#
, must also be supplied. With a #tex2html_wrap_inline4110#
2 system, of course, the acceleration of a particular galpixel does not change at all while the video controller propagates the scene from frame to frame; however, it would be wrong to think that the <#717#>matrix<#717#> of galpixel acceleration values similarly stays constant under propagation. The reason, of course, is that <#718#>each galpixel carries its velocity and acceleration data along with it<#718#>; in physics terms, these quantities are <#719#>convective<#719#> temporal derivatives (``carried along'' with the flow), <#720#>not<#720#> partial temporal derivatives (which stay put in space). It should be noted that this concept---that a ``<#721#>gal<#721#>pixel'' is a little pixelated logical object moving around the display, whereas a plain ``pixel'' is simply a static position in the frame buffer matrix---will be used extensively in the following description.

The next questions that must be considered are: What numerical format should we store the velocity and acceleration information in? How many bits will be needed? These questions are of extreme importance for the implementation of any ed technology. That this is so can be recognised by calculating just how many such quantities need to be stored in the video hardware subsystem: We need both a velocity and an acceleration value for every galpixel in a frame buffer. Velocity and acceleration each have three components. We need at least three such frame buffers for each display device (two for the video controller to propagate between, and one for the display processor to play with at the same time); and, for stereoscopic displays, will need two (logical) display devices. Even for a bare-minimum display resolution of (say) #math121#320×200, we are looking down the barrel at 2.3~million quantities that need to be stored somewhere; increasing the resolution to #math122#640×480 blows this out to 11~million quantities. Of course, with RAM currently on the street for A$45 per megabyte, even a relatively wasteful implementation of memory would not blow out the National Deficit on RAM chips alone; however, configuring such a memory structure in terms of electronic devices, in such a way that it can be processed at video-rate speeds, is a challenging enough task without having to deal with an explosion of complexity.

Let us, therefore, make some crude estimates as to how we would like our physical system to perform. Assume, for argument's sake, that we are implementing a 50~Hz refresh rate display system; each frame period is then 20 milliseconds. Propagating quantities forward with a finite numerical accuracy leads to accumulated errors that increase with time. In particular, the position of an object will be ``extrapolated'' poorly if we retain too few significant figures in the velocity and acceleration---even ignoring the fact that the acceleration of the object may have, in fact, changed in the mean time. How poor a positional error, arising from numerical accuracy alone, can we tolerate? Let us say that this error should be no worse than a single pixel or so. But the error in position will, in a worst case scenario, increase linearly with time, number of extrapolated frames. How many frames will we want to extrapolate forwards while still maintaining one-pixel accuracy? Well, since we will be using binary arithmetic eventually, let's choose a power of 2---say, 16 frames. This corresponds to an inter-update time ( the time for which the video controller itself happily propagates the motion of the galpixels between display processor updates) of 320~milliseconds---which should be <#722#>more<#722#> than enough, considering that the participant's acceleration (not to mention that of the objects in the virtual world) will have no doubt changed by a reasonable amount by then---and the view, if it has not been updated by the display processor, will thus be reasonably inaccurate anyway. Of course, the whole display system won't suddenly fall over if, in some situation, we don't actually get a display processor update for more than 16 frames---it is just that the inherent numerical inaccuracy of the propagation equations will simply grow larger than 1~pixel. We shall say that the display system is <#1666#>rated for a #math123#N<sub>#tex2html_wrap_inline4114#</sub>
prop = 16 propagation time<#1666#>---a number that would appear in its ``List of Specifications'' at the back of the Instruction Manual.

OK, then, how do we use our design choice of #math124#N_{#tex2html_wrap_inline4116#}
prop (16, in our case) to determine the accuracy of the velocity and acceleration that we need to store? The answer to that question is, in fact, inextricably intertwined with the particular equation that our hardware will use to propagate galpixels across the display---and, in particular, how it is implemented with finite-accuracy arithmetic---which must therefore be brought to the focus of our attention. Now, we have learnt from our Virtual Galileo, in section~<#725#>Motion<#725#>, that the formula for the trajectory of a uniformly accelerated object is given by <#726#>UniformAccelPosVecVersion<#726#> (t)=(0)+(0)t+t^2, and, from this, the equation of motion for its velocity is given by <#727#>UniformAccelVelVecVersion<#727#> (t)=(0)+t. Since our video controller only knows about our galpixel's initial position #tex2html_wrap_inline4118#
(0), initial velocity #tex2html_wrap_inline4120#
(0) and initial acceleration #tex2html_wrap_inline4122#
(0) anyway, assuming a <#728#>constant<#728#> acceleration #math125##tex2html_wrap_inline4124#
#tex2html_wrap_inline4125#
#tex2html_wrap_inline4126#
(0) for the galpixel (until the next display processor update) is about the most reasonable thing to do. If we measure t in units of the frame period---which we shall always do in the following---we can compute <#729#>exactly<#729#> where the uniformly-accelerated object would be, and what its velocity would be, at the time of the next frame, by simply inserting t = 1 into <#730#>UniformAccelPosVecVersion<#730#> and <#731#>UniformAccelVelVecVersion<#731#>, giving <#732#>PropPos<#732#> _i(1)=_i(0)+_i(0)+_i and <#733#>PropVel<#733#> _i(1)=_i(0)+_i respectively. We now note that, to our delight, the arithmetical operations needed to compute <#734#>PropPos<#734#> and <#735#>PropVel<#735#> are not only simple---<#736#>they can actually be hard-wired!<#736#> The most ``complicated'' operation we need to perform is (signed) addition, for which a hardware implementation is trivial. And since we will be employing binary numbers, taking half of #tex2html_wrap_inline4130#
, as required in <#737#>PropPos<#737#>, amounts to simply shifting it right one bit---or, in the hard-wired-adder version of <#738#>PropPos<#738#>, simply connecting the signals appropriately shifted. Thus, we can already see why it <#739#>is<#739#> technologically feasible to propagate motion using #tex2html_wrap_inline4132#
2 antialiasing, even at video rates---the required computations are, by cidence, trivial for the digital devices that we have at our disposal.

Now, using <#741#>PropPos<#741#> and <#742#>PropVel<#742#>, how many fractional bits do we need to store for #tex2html_wrap_inline4134#
, #tex2html_wrap_inline4136#
and #tex2html_wrap_inline4138#
to ensure 1-pixel accuracy at #math126#N_{#tex2html_wrap_inline4140#}
prop = 16? At this point, we come to a horrible realisation: <#744#>we cannot have any fractional bits at all!<#744#> Why do we reach this conclusion? Because, as noted earlier, the x and y components of the #tex2html_wrap_inline4144#
information for the galpixel is already encoded in its position in the pixmap matrix...and there's no fractional part to a position in a matrix! And without any fractional bits in #tex2html_wrap_inline4146#
, performing the addition in <#745#>PropVel<#745#> with fractional bits in #tex2html_wrap_inline4148#
or #tex2html_wrap_inline4150#
would be a complete waste of time: the fractional bits would be thrown away each frame as we write the galpixel into its new position! <#746#>A catastrophe!<#746#>

Recovering our composure, we ask: What happens if we <#747#>are<#747#> restricted to having integral #tex2html_wrap_inline4152#
and #tex2html_wrap_inline4154#
? Is that good enough? Well, let us consider just the velocity for the moment, and assume the acceleration is zero. Clearly, if #tex2html_wrap_inline4156#
= 0 also, the galpixel won't move anywhere at all until the next display processor update. This is appropriate if the galpixel wasn't supposed to move more than half a pixel in any direction anyway. OK, then, what is the next smallest speed possible? Let us consider just the x direction, for simplicity. The smallest value for v^x_i, in integer arithmetic, is, obviously, #math127#v^x_i = ±1. What will the video controller do with such a galpixel? It will move it one pixel per frame until the next update. But this is terrible---that's a whole 16 pixels (if we wait 16 frames for a display processor update); the thing is moving at 50 pixels per second! And that's the <#748#>smallest<#748#> non-zero speed we can define! What happens if the galpixel should have been moving at 24 pixels per second? Too bad---it stays put. And if it should have been going at 26 pixels per second? Sorry, 50 is all I can give you. You'll just have to overshoot. <#749#>A catastrophe!<#749#>

Regaining our composure again, let us reconsider the reason why the proverbial hit the fan in the first place. Our basic problem is that a pixmap matrix has no such thing as a ``fractional row'' or ``fractional column''. Maybe we could increase the resolution of our display...and call the extra pixels ``fractions''? Hardly a viable proposition in the real world---and in any case we'd be simply palming off the problem to the <#750#>new<#750#> pixels. Maybe we could leave the display at the same resolution, but replace each entry in the galpixmap with a little galpixmap matrix of its own? Then we could have ``fractional rows and columns'' no problems! Well, how big would the little matrix need to be? Seeing as a velocity of v^x_i = 1 pixel per frame moves us by 16 pixels in 16 frames---and we only want to move one pixel, max., in this time period---we should therefore reduce the minimum computable velocity to 1/16 of a pixel per second. This, then, requires a #math128#16×16 sub-galpixmap for each display pixel. We'd need 256 times as much memory as we've already computed before---2.3~millions quantities blows out to almost 600~million! <#751#>A catastrophe!<#751#>

Regaining our composure for the third (and final) time, let us consider this last proposal a little more rationally. We uncontrollably assumed that what was needed at each pixel location was a little galpixmap, with all the memory that that requires. Do we really need all this information? What would it mean, for example, to have a whole lot of little ``baby galpixels'' moving around on this hugely-expanded grid? What if the babies of two different (original-sized) galpixels end up on the same (original-sized) galpixel submatrix---does such a congregation of babies make any conceptual sense? Well, our display device only has <#752#>one<#752#> pixel per submatrix: so who gets it? Do we add, or average, the colour or intensity values for each of the baby galpixels? No---the object <#753#>closer<#753#> to the viewer should obscure the other. Should it be ``most babies wins''? No, for the same reason. Then is there any reason for having baby galpixels at all? It seems not.

Let us, therefore, look a little more closely at these last considerations. Since the display device only has one physical pixel per stored galpixel (of the original size, that is---the baby galpixels having now been adopted out), then, obviously, a galpixel can only move one pixel at a time anyway. But we only want to move the galpixel by one pixel every 16 frames---or every 3 or 7 or 13 frames, or whatever time period will, on the average, give us the right average apparent velocity of the galpixel in question. So how does one specify that the video controller is to ``sit around'' for some number of frames before moving the galpixel? Simple---put in a little counter, and tell it how many frames to wait. Of course, we need a little counter for each galpixel, but it need only count up to 16, so it only needs 4 bits anyway (in each of the x and y directions)---not a large price. Thus, we <#754#>can<#754#> get sub-pixel-per-frame velocities, with only a handful extra bits per galpixel!

Let us look at this ``counter'' idea from a slightly different direction. Just say that we have told the video controller to count up to 16 before moving this particular galpixel one pixel to the right. Why not <#755#>pretend<#755#> that, on each count, the galpixel ``really <#756#>is<#756#>'' moving 1/16 of a pixel to the right---just that we don't actually see it move because our display isn't of a high enough resolution. Rather, the galpixel says to itself on each count, ``Hmm, this display device doesn't have any fractional positions; I'll just throw away the fraction and stay here.'' But then, upon reaching the count of 16, the galpixel says, ``Hey, now I'm supposed to be 16/16 pixels to the right---but that's one <#757#>whole<#757#> pixel, and I can do that!'' Clearly, this is a better description for the counter than our original one---we now know what to do if counting, say, by 3s---namely, we count up #math129#3, 6, 9, 12, 15, 18..., whoops! total is over 16---so move right one pixel and ``clock over'' to a count of #math130#2, 5, 8, 11,…; and so on.

And so we come---by a rather roundabout route, to be sure---to the conclusion that the <#758#>simplest<#758#> way to allow sub-pixel-per-frame velocities is to ascribe to each galpixel two additional attributes: a <#759#>fractional position<#759#> in each of the x and y directions. The above roundabout explanation has, as a consolation prize, already told us how many bits of fractional positional information we require for a #math131#N_{#tex2html_wrap_inline4175#}
prop = 16 rated system, namely, 4, for each of the x and y directions. Clearly, the number of bits required in the general case is just equal to #math132#(log₂N_{#tex2html_wrap_inline4179#}
prop), 3 bits for #math133#N_{#tex2html_wrap_inline4181#}
prop = 8; 5 bits for #math134#N_{#tex2html_wrap_inline4183#}
prop = 32, and so on.

There is, however, a slightly undesirable feature of the above specification of the action of fractional position, that we must now repair. In the example given, the galpixel ``moved'' 1/16 of a pixel each frame; on the 16th frame it moved to the right by one physical display pixel. Is this appropriate behaviour? Consider the situation if the galpixel had in fact been moving with an x-direction velocity of <#764#>minus<#764#> one-sixteenth of a pixel per frame. On the first frame, it would have <#765#>decremented<#765#> its fractional position---initially zero---and ``reverse clocked'' back to a count of 15, simultaneously moving to the <#766#>left<#766#> by one physical display pixel. But this is crazy---if it takes 16 frames to move one pixel right, why does it only take one frame to move one pixel left, if it is supposed to be moving at the <#767#>same speed<#767#> ( 1/16 pixels per frame)? Clearly, we have been careless about our arithmetic: we have been <#768#>truncating<#768#> the fractional part off when deciding where to put the pixel on the physical display; we should have been <#769#>rounding<#769#> the fraction off. Implementing this repair, then, we deem that, if a fractional position is greater than or equal to one-half, the physical position of the galpixel in the galpixmap matrix is incremented, and the fractional part is decremented by 1.0. (Of course, there is no need to <#770#>actually<#770#> do any decrementing in the fractional bits---one just proclaims that 1000₂ represents a fraction -8/16; 1001₂ represents -7/16; and so on, up to 1111₂ representing -1/16.) With this repair, a galpixel with a constant speed of 1/16 pixels per frame (and initial fractional position of zero, by definition!) will take 8 frames to move one pixel if moving to the right, and 9 frames (by reverse clocking over #math135#-8/16→ -9/16#tex2html_wrap_inline4195#
+ 7/16 if moving to the left---as symmetrical a treatment as we are going to get (or, indeed, care about).

There is one objection, however, that might be raised at this point: we originally constructed our fractional position carefully, with the correct number of bits, so that the galpixel would be able to wait up to 16 frames before having to move one pixel. Why have we now restricted this to only 8 (or 9) frames? The answer is that we haven't, really; the motion still <#771#>is<#771#> at a speed of 1/16 pixels per frame. To see this, one need only continue the motion on for a longer time period: the displayed pixel ``jumps'' at frames #math136#8, 24, 40,…, and so on. It is only in order to assure a left--right (and up--down) symmetric treatment of the motion that the <#772#>first<#772#> eight or nine frames seem strange, at first sight. Looked at another way, consider <#773#>successive<#773#> display processor updates, spaced 16 frames apart, for a galpixel that is, in fact, moving at the constant velocity of 1/16 frames per second. On the first update, the galpixel is at x = 0 (say); on frame number 8 it moves one physical pixel to the right, to x = 1. For the remaining 7 extrapolated frames of the first update period, it doesn't move; at the end of this time, its fractional position is -1/16, with respect to its physical position of x = 1. Then the second update comes. The galpixel is now painted in at x = 1, with a fractional position of zero---exactly as it would have been if the previous frame has simply been propagated. <#774#>This<#774#> galpixel now waits 8 frames before moving to x = 2. Does this mean that it is actually moving at a rate of 1/8 pixels per frame, rather than 1/16 are desired? No---one must add the 7 frames of the <#775#>previous<#775#> update period, plus the update frame, to these 8 frames---making a total of 16 frames since it had last moved, just as we wanted! Of course, the display processor in some sense ``destroys'' the previous galpixel when it draws the new one in the update frame, and so in that sense it's not truly the ``same'' galpixel that accumulates the two halves of the 16-frame waiting period. However, the whole idea of a #tex2html_wrap_inline4209#
2 display system is precisely to make it <#777#>look<#777#> as if this is the same galpixel moving along---which, if the true motion is reasonably well approximated by uniform acceleration, and if the inter-update time is not too excessive, will indeed be the case. On the other hand, if the motion is <#778#>not<#778#> well approximated by uniform acceleration, then it must necessarily be ``jerking around'' a bit---and now we rely on the <#779#>psychological<#779#> observation that, in such circumstances, small details are difficult to discern! Of course, if the viewer puts herself in such a position to ``take a better look'' at the object represented by the galpixel, then, by the very <#780#>definition<#780#> of ``taking a better look'' ( stabilising the apparent motion of the object in one's field of view), the gross jerkiness has been transformed away, and the display is again accurate! It should be now apparent why psychological criteria played such an important in the decisions made in the previous section---they effectively ``save our bacon'' when things get technically difficult!

We now turn to the question of determining how many bits of accuracy are required for the velocity and acceleration components themselves, for the example of a #math137#N_{#tex2html_wrap_inline4211#}
prop = 16 system. It might be thought that, since the position information is only accurate to four bits itself, then equation~<#782#>PropPos<#782#> means that any more than four bits in #tex2html_wrap_inline4213#
or #tex2html_wrap_inline4215#
would be wasted. However, this conclusion would be erroneous: one must take into account equation~<#783#>PropVel<#783#> as well. It is clear that #tex2html_wrap_inline4217#
(t) or #tex2html_wrap_inline4219#
might well continue to be propagated from frame to frame at a <#784#>higher<#784#> accuracy than four bits, which would then feed through, indirectly, to equation~<#785#>PropPos<#785#>, through the velocity velocity #tex2html_wrap_inline4221#
(t).

Let us, therefore, examine this question a little more closely. Consider, now, not the i-th galpixel travelling with constant <#786#>velocity<#786#>, but, rather, travelling under the effect of a constant <#787#>acceleration<#787#> #tex2html_wrap_inline4224#
. Imagine, for simplicity, that the initial velocity of the galpixel, #tex2html_wrap_inline4226#
(0), is zero, as is its initial position #tex2html_wrap_inline4228#
(0), and that its acceleration #tex2html_wrap_inline4230#
is purely in the x-direction: #math138##tex2html_wrap_inline4233#
= (a, 0, 0). The x-motion of this galpixel will clearly then be given by <#788#>Parabolic<#788#> x(t)=at^2. Now consider how far this galpixel travels from the time t = 0 to the time #math139#t = N_{#tex2html_wrap_inline4237#}
prop = 16 frame periods: this distance is clearly #math140##tex2html_wrap_inline4239#
⋅a⋅(16)² = 128a pixels. If we want the minimum specifiable distance travelled after #math141#t = N_{#tex2html_wrap_inline4241#}
prop = 16 frame periods to be 1~pixel, we therefore require a <#791#>minimum specifiable acceleration<#791#> of 1/128 pixels per frame per frame, or, in other words, we require <#792#>seven fractional bits<#792#> for the acceleration, not four. In the general case, of arbitrary #math142#N_{#tex2html_wrap_inline4244#}
prop, the number of bits required for the acceleration is clearly #math143#(2 log₂N_{#tex2html_wrap_inline4246#}
prop - 1); the factor of 2 arises from the fact that the time is <#795#>squared<#795#> in equation~<#796#>Parabolic<#796#> (since #math144#log a²#tex2html_wrap_inline4248#
2 log a), and the subtraction of 1 from the result arises from the fact that we divide the acceleration by #tex2html_wrap_inline4250#
in equation~<#797#>Parabolic<#797#> (since #math145#log₂(a/2)#tex2html_wrap_inline4252#
log₂(a) - 1). Thus, for example, for #math146#N_{#tex2html_wrap_inline4254#}
prop = 8 we would require 5 fractional bits for the acceleration; for #math147#N_{#tex2html_wrap_inline4256#}
prop = 32 we would require 9 bits; and so on.

What, then, does this requirement of 7 bits for the fractional part of each component of #tex2html_wrap_inline4258#
(for our example of #math148#N_{#tex2html_wrap_inline4260#}
prop = 16) mean for the required accuracy of the <#801#>velocity<#801#> vector, #tex2html_wrap_inline4262#
? Clearly, <#802#>PropPos<#802#> cannot carry more than four bits of information, since the position is only stored from frame to frame with this accuracy. The responsibility for propagating the information from the full 7 fractional bits of the acceleration <#803#>must<#803#> therefore be carried by equation <#804#>PropVel<#804#>. Thus, <#805#>the velocity also needs to have 7 bits of fractional accuracy<#805#>---or, in the general case, #tex2html_wrap_inline4264#
must have the same number of bits as #tex2html_wrap_inline4266#
, namely, #math149#(2 log₂N_{#tex2html_wrap_inline4268#}
prop - 1).

We must now consider the problem of how we should add together the various differing-accuracy numbers in <#807#>PropPos<#807#>: #tex2html_wrap_inline4270#
has 4 fractional bits, #tex2html_wrap_inline4272#
has 7, and #math150##tex2html_wrap_inline4274#
#tex2html_wrap_inline4275#
has 8 (once we have multiplied it by the half, shifted it right one bit). The thing to do would be to simply compute it at the accuracy of #tex2html_wrap_inline4277#
---or 4 fractional bits in our example. However, this would <#808#>unnecessarily<#808#> throw away information that is already contained in the last three bits #tex2html_wrap_inline4279#
, and the last four bits of #math151##tex2html_wrap_inline4281#
#tex2html_wrap_inline4282#
. The <#809#>correct<#809#> procedure is to add #tex2html_wrap_inline4284#
and #math152##tex2html_wrap_inline4286#
#tex2html_wrap_inline4287#
together with <#810#>a full 8 bits<#810#> of accuracy; then to <#811#>round<#811#> this number off to the nearest 4-bit-fraction number. (This <#812#>rounding<#812#> can be effected in the same step by simply adding the number #math153#0.00001000₂ to the sum of #tex2html_wrap_inline4290#
and #math154##tex2html_wrap_inline4292#
#tex2html_wrap_inline4293#
, and then <#813#>truncating<#813#> the result to four bits.) This four-bit number should then be added to the current fractional position, as in <#814#>PropPos<#814#>. In this way we utilise the information stored in the #tex2html_wrap_inline4295#
2 frame buffer optimally.

We now turn the question of the accuracy required for the z-buffer position, velocity and acceleration information. Clearly, there is no advantage to thinking in terms of ``fractional'' bits in the z direction <#816#>per se<#816#>---because the visual information is not matricised in that direction anyway. Rather, one must simply allocate a sufficient number of bits for the z-buffer to ensure that the finest movement in this direction that the application software requires can be accurately <#817#>propagated<#817#> over the rated propagation time #math155#N_{#tex2html_wrap_inline4300#}
prop. It should be noted that, in general, this will require a <#819#>greater<#819#> number of bits for the z-buffer than for the same system without ing, for the same reasons as applied to the use of fractional positional data in the x and y directions.

An interesting problem arises when an existing hardware z-buffer is in place which, for ing purposes, is not of a sufficiently high number of bits to meet the design specifications for the applications intended for use. In such a case, it <#820#>is<#820#> useful to think of adding ``fractional bits'' to the z-buffer; these extra bits are then stored in a new <#821#>physical<#821#> memory device, but in all respects are <#822#>logically<#822#> appended to the trailing end of the corresponding z-buffer values already implemented in hardware. The controlling software may then choose to either compute z values to the full accuracy of this extended z-buffer; or, for backwards compatibility with older applications, may choose to simply specify only integral z-buffer values, using the fractional bits purely to ensure rated performance under propagation.

We now turn to the question of how many <#823#>integral<#823#> bits are required for the velocity #tex2html_wrap_inline4311#
and acceleration #tex2html_wrap_inline4313#
of the i-th galpixel. This question is less straightforward than determining the number of fractional bits, as above, and to some extent depends on the experience and opinions of the designer of the system. Clearly, the maximum velocity portrayable on the display device is equal to one display width or height in the period of one frame. Any higher velocity than this and the galpixel in question either wasn't visible on the previous frame, or else won't be on the subsequent frame. Since practical displays are currently limited, in rough terms, to a maximum resolution of around #math156#1000×1000 at best, this suggests that no more than 10 integral bits need be stored for each Cartesian component of #tex2html_wrap_inline4317#
(since #math157#2¹⁰ #tex2html_wrap_inline4319#
1000). This estimate, however, is too generous, because the human visual system cannot even <#825#>see<#825#> an image that appears on a display for only a single frame, let alone recognise it. More useful would be to consider as a limiting velocity a traversal of the entire display <#1667#>over a period of #math158#N_{#tex2html_wrap_inline4321#}
prop frames<#1667#>. For #math159#N_{#tex2html_wrap_inline4323#}
prop = 16, this suggests that about six integral bits for each component of velocity may be sufficient to portray the maximum visualisable apparent velocity; in the general case of a display of linear dimension D pixels, this estimated number of integral bits is simply given by the formula #math160#(log₂D - log₂N_{#tex2html_wrap_inline4326#}
prop).

One must, however, also take in account the <#829#>acceleration<#829#>, #tex2html_wrap_inline4328#
, in these considerations, as may be seen in the following example: Imagine that there is a virtual projectile being displayed that is shot up from the bottom of the display, rises <#830#>just<#830#> to the top of the display under the simulated effect of gravitation, and then falls back to the bottom of the display. If we assume that the most rapid motion of this sort visualisable by the viewer should also take place over a time interval of #math161#N_{#tex2html_wrap_inline4330#}
prop frames, we can compute the corresponding maximum velocity and acceleration of the galpixel exactly. Using Galileo's equations of motion #math162#y_i(t) = y_i(0) + v_i^y(0) + #tex2html_wrap_inline4332#
a_i^yt² and #math163#v_i^y(t) = v_i^y(0) + a_i^yt, the above motion can be described by the constraints y_i(0) = 0 (say), #math164#y_i(N_{#tex2html_wrap_inline4336#}
prop/2) = D, and #math165#v_i^y(N_{#tex2html_wrap_inline4338#}
prop/2) = 0. The first constraint tells us that y_i(0) = 0 (obviously); the second that

#math166#

#math167#

#math168#